This chapter describes the Bandwidth Reservation System and priority queuing features currently available for Frame Relay and PPP interfaces. It includes the following sections:
The Bandwidth Reservation System (BRS) allows you to decide which packets to drop when demand (traffic) exceeds supply (throughput) on a network connection. When bandwidth utilization reaches 100%, BRS determines which traffic to drop based on your configuration.
Bandwidth reservation "reserves" transmission bandwidth for specified classes of traffic. Each class has an allocated minimum percentage of the connection's bandwidth. See Figure 1 and Figure 2.
On PPP interfaces, you define traffic classes (t-classes) and each traffic class is allocated a percentage of the PPP interface's bandwidth. There are at least two traffic classes:
You can create additional traffic classes and assign protocols, filters and tags to the priority queues within a traffic class. See Figure 1.
On Frame Relay interfaces, you define circuit classes (c-classes) and each circuit class is allocated a percentage of the Frame Relay interface's bandwidth. There is at least one circuit class: the DEFAULT circuit class to which all circuits are initially assigned. You can create additional circuit classes and assign circuits to these c-classes. On each Frame Relay circuit, you can define traffic classes (t-classes) and each traffic class is allocated a percentage of the Frame Relay circuit's bandwidth. The traffic class support for Frame Relay circuits is analogous to the traffic class support for PPP interfaces. See Figure 2 for the Frame Relay Circuit Class and Traffic Class Relationships.
Figure 1. PPP BRS Traffic Class and Traffic Class Priority Queue Relationship
Traffic Percentage of
Class Interface Bandwidth Priority Queue Type of Traffic
.--------
| LOCAL 10%
| .----
| | URGENT (Protocol, Tag, Filter)
| | HIGH (Protocol, Tag, Filter)
| DEFAULT 40% | NORMAL Protocol (Tag, Filter)
PPP | | LOW (Protocol, Tag, Filter)
Connection | '----
(BRS [i #]) | .----
| | URGENT (Protocol, Tag, Filter)
| | HIGH (Protocol, Tag, Filter)
| CLASS A xx% | NORMAL (Protocol, Tag, Filter)
| | LOW (Protocol, Tag, Filter)
'-------- '----
Note: All protocols are initially assigned to the NORMAL priority queue of the
DEFAULT traffic class. You can assign a protocol, filter, or tag to any
priority queue within a traffic class.
Figure 2. Frame Relay BRS Circuit Class and Traffic Class Relationship
Circuit Bandwidth
Class Percentage
.--------- (BRS [i #] [dlci #] Config>)
| Circuit BRS Traffic Class
| Number Filtering Specification
| .----------
| | 16 enabled using default *
| |
| DEFAULT 40% | 17 disabled no traffic filtering
| |
| | 18 enabled circuit specific:
| '----------
| LOCAL 10%
| .---
| | URGENT (protocol, tag, filter) DE **
| DEFAULT 40% | HIGH (protocol, tag, filter) DE
| | NORMAL protocol (tag, filter) DE
| | LOW (protocol, tag, filter) DE
| '---
|
Frame Relay | .------------
Connection | CLASS A xx% | 20 using defaults *
| |
(BRS [i #] Config>) | | 21 using defaults *
| '------------
| .
| .
| .
|
| Other circuit class definitions ...
| ** Represents that the data is discard eligible
|--------------------------------------------------------------------------------------
| * Default circuit traffic class definitions (BRS [i #] [Circuit Default] Config>)
|
| LOCAL 10%
| .---
| | URGENT (protocol, tag, filter) DE
| DEFAULT 40% | HIGH (protocol, tag, filter) DE
| | | NORMAL protocol (tag, filter) DE
| | | LOW (protocol, tag, filter) DE
| | '---
| |
|
| % of Circuit class allocation for traffic class
'---------
Note: All protocols are initially assigned to the NORMAL priority queue of the
DEFAULT traffic class. You can assign a protocol, filter, or tag to any
priority queue within a traffic class.
These reserved percentages are a minimum slice of bandwidth for the network connection. If a network is operating to capacity, messages in any one class can be transmitted only until they use the configured bandwidth allocated for the class. In this case, additional transmissions are held until other bandwidth transmissions have been satisfied. In the case of a light traffic path, a packet stream can use bandwidth exceeding its allowed minimum up to 100% if there is no other traffic.
Bandwidth reservation is really a safeguard. In general, a device should not attempt to use greater than 100% of its line speed. If it does, a faster line is probably needed. The "bursty" nature of traffic, however, can drive the requested transmission rate to exceed 100% for a short time. In these cases, bandwidth reservation is enabled and the higher priority traffic is ensured delivery (that is, is not discarded).
Bandwidth reservation runs over the following connection types:
Bandwidth reservation allows you to reserve bandwidth at two levels:
When BRS receives a packet from Frame Relay, the configured c-classes and t-classes are used to determine when that packet will be transmitted. BRS queues the packet according to these criteria: c-class, circuit, t-class, and priority within the t-class. The c-class to which the circuit has been assigned is put onto a queue of c-classes and the queue of c-classes is sorted according to a fair weighted queuing algorithm. Within a c-class, circuits that have packets to be transmitted are serviced in a round robin fashion. The t-classes within each c-class are also sorted according to a fair weighted queuing algorithm. Within the t-class, packets are further queued according to their priority (urgent, high, normal, or low).
A packet is removed from the queue and transmitted when it meets all these criteria:
When you enable the interface and one or more circuits for BRS and do not configure any c-classes or t-classes, all the circuits are assigned to one c-class called default. With this configuration, there will be only the default c-class on the queue of c-classes and each of the circuits in the c-class with packets for transmission will be handled in a round robin order. If you want BRS to do this, leave all circuits in the default c-class and do not create any other circuit classes.
Orphaned circuits and circuits without BRS explicitly enabled use this default BRS queuing environment in all situations. BRS assigns them to the default c-class.
To configure BRS, you should follow this sequence:
You can use several bandwidth reservation monitoring commands to display reservation counters for the circuit classes for a given interface:
See "Configuring and Monitoring Bandwidth Reservation" for more information on monitoring BRS.
The interface is the one shown at your prompt for the bandwidth monitoring commands. For example, BRS [i 5] is the prompt for interface 5.
With bandwidth reservation over Frame Relay, each circuit can queue frames while in the congested state, even for interfaces and circuits that are not enabled for bandwidth reservation.
The Frame Relay network may discard transmitted data exceeding CIR on a PVC. The DE bit can be set by the router to indicate that some traffic should be considered discard eligible. If appropriate, the Frame Relay network will discard frames marked as discard eligible, which may allow frames that are not marked discard eligible to make it through the network. When assigning a protocol, filter, or tag to a traffic class, you can specify whether or not the protocol, filter, or tag traffic is discard eligible. See "Assign" for more information on how to configure traffic as discard eligible. Voice traffic (identified by the protocol VOFR) should always be configured as not discard-eligible.
Frame Relay interfaces can have many circuits defined. Rather than having to fully configure traffic class definitions for each circuit, BRS allows you to define a default set of traffic classes and protocol, filter, and tag assignments called default circuit definitions that can be used by any circuit on the interface. When BRS is initially enabled on a circuit, the circuit is initialized to use default circuit definitions. If a circuit cannot use the default circuit definitions for traffic class handling then you can create circuit-specific definitions by using the add-class, change-class, assign, deassign, tag, and untag commands.
If a circuit is using circuit specific definitions and you want it to use the default circuit definitions instead, you can use the use-circuit-defaults command at the circuit's BRS prompt.
The default circuit definitions for traffic class handling are defined by using the set-circuit-defaults at the BRS Frame Relay interface prompt. This command gets you to a BRS circuit defaults prompt where you can add, change, and delete traffic classes, assign and deassign protocols, filters, and tags, and create BRS tags. Changes to the default circuit definitions for traffic classes result in dynamic updates to the traffic class handling for all circuits using the default circuit definitions.
Voice frames can be transported over dedicated circuits. In this situation, enable BRS on the interface and on the circuits and accept the defaults on circuits associated with voice. You may want to create multiple c-classes and assign the circuits dedicated to voice to a c-class which is associated with a large bandwidth percentage and assign the circuits associated with data to a circuit class associated with a smaller bandwidth percentage.
If voice and other traffic are both transported over the same circuits, enable BRS on the interface and circuits. If you want all circuits serviced in a round robin fashion without favoring one or more circuits you may decide not to create additional c-classes beyond the default c-class. Then, for each circuit over which both voice and data will be transported, it is suggested that you create a t-class with the create-super-class command and assign your VOFR traffic to this class. Also create additional t-classes as needed and assign other types of traffic to these t-classes. This configuration will help to ensure that voice traffic gets priority over all other traffic and that unsegmented voice frames can be interleaved between fragmented data segments if fragmentation is enabled. It is recommended that you enable fragmentation on the Frame Relay interface if you will be sending voice and data over the same interface. Fragmentation will result in smaller frames and thus a smaller delay between consecutive voice frames.
Refer to the enable fragmentation command in the chapter "Configuring and Monitoring Frame Relay Interfaces" in the Access Integration Services Software User's Guide for more information about enabling fragmentation.
Bandwidth reservation allocates percentages of total connection bandwidth for specified traffic classes, or t-classes, defined by the user. Except for a t-class created by the create-super-classpubs command which has priority over all other t-classes, BRS t-classes are associated with a bandwidth percentage. Protocols and filter data can be assigned to t-classes and to specific priority queues within a t-class. With priority queuing, a protocol or filter can be assigned to a specific queue within a traffic class with settings: A BRS t-class is a group of packets identified by the same name; for example, a class called "ipx" to designate all IPX packets.
With priority queuing, each bandwidth t-class can be assigned one of the following priority level settings:
for specified traffic classes, or t-classes, defined by the user.
Also, you can set the number of packets that are waiting in the queue for each priority level in each bandwidth t-class. The BRS queue-length command sets the maximum number of output buffers that can be queued in each BRS priority queue, and the maximum number of output buffers that can be queued in each BRS priority queue for when router input buffers are scarce. You can set up priority queue lengths for both PPP and Frame Relay.
Attention: If you set the values for queue length too high, you may seriously degrade the performance of your router.
For BRS, you can set priority queue lengths for PPP and Frame Relay WAN connections. See "Queue-length" for a description of the queue-length command.
The priority settings in one bandwidth t-class have no effect on other bandwidth classes. No one bandwidth class has priority over the others.
When priority queuing is configured without bandwidth reservation, the highest priority traffic is delivered first. In instances of heavy high-priority traffic, lower priority levels can be overlooked. By combining priority queuing with bandwidth reservation, however, packet transmission can be allocated to all types of traffic.
You create a traffic class using the add-class command and then assign types of traffic to the class using the assign command. Traffic is assigned to a traffic class based on its protocol type or based on a filter that further identifies a specific type of protocol traffic (for example, SNMP IP packets).
Supported protocol types are:
Using bandwidth reservation, you can treat specific protocol traffic differently from other traffic that is using the same protocol type. For example, you can assign SNMP IP traffic to a different traffic class and priority than other IP traffic. In this example, SNMP is a BRS filter because it filters (that is, uniquely identifies) specific protocol traffic. IP, ASRT (bridging) and APPN-HPR protocol traffic can be filtered by bandwidth reservation. The following filters are supported:
The following sections describe how to use BRS with various types of filtering.
MAC Address filtering is handled by a joint effort between bandwidth reservation and MAC filtering (MCF) using tags. For example, a user with bandwidth reservation is able to categorize bridge traffic by assigning a tag to it.
The tagging process is done by creating a filter item in the MAC filtering configuration console and then assigning a tag number to it. This tag number is used to set up a traffic class for all packets associated with this tag. Tag values must currently be in the range 1 through 64. See "Using MAC Filtering" for additional information about MAC filtering.
| Note: | Tags can be applied only to bridged packets. On a PPP or Frame Relay connection, up to five tagged MAC filters can be assigned as bandwidth reservation filters and are designated as TAG1 through TAG5. TAG1 is searched for first, then TAG2, and so on up to TAG5. A single MAC filter tag can consist of any number of MAC Addresses set in MCF. |
Once you have created a tagged filter in the MAC filtering configuration process, you can use the BRS tag configuration command to assign a BRS tag name (TAG1, TAG2, TAG3, TAG4, or TAG5) to the MAC filter tag number. Then use the BRS tag name on the BRS assign command to assign the corresponding MAC filter to a bandwidth traffic class and priority.
Tags also can refer to "groups," as in the example of IP Tunnel. IP Tunnel endpoints can belong to any number of groups. Packets are assigned to a particular group through the tagging feature of MAC Address filtering. For additional information on MAC filtering, refer to "Using MAC Filtering" and "Configuring and Monitoring MAC Filtering".
To apply bandwidth reservation and queuing priority to tagged packets:
You can assign TCP/IP packets from a range of TCP or UDP ports to a BRS t-class and priority based on the packet's UDP or TCP port number and, optionally, upon a socket. You can specify up to 5 UDP/TCP port number filters, where the filters specify either an individual TCP or UDP port number, a range of TCP or UDP port numbers, or a socket identifier (combination of port number and IP address). You can then assign that filter to a BRS traffic class and priority within the class.
If UDP/TCP port filtering is enabled, BRS looks at each TCP or UDP packet and checks to see if the destination or source port number matches one of the port numbers you have specified for filtering. Also, if you define an IP address as part of the BRS UDP/TCP filter and the destination or source IP address matches the filter address you define, BRS assigns the packet to the traffic class and priority for that port number filter.
For example, you can configure a UDP port number filter for UDP port numbers in the range 25 to 29 and assign the filter to traffic class 'A' with a priority of 'normal'. BRS queues any UDP packets with a source or destination port number from 25 to 29 on the normal priority queue for traffic class 'A'.
You can also configure a TCP port number filter for TCP port number 50 for IP address 5.5.5.25 and assign the filter to traffic class 'B' with priority 'urgent'. BRS queues any TCP packets whose source or destination port number is 50 and whose destination or source IP address is 5.5.5.25 on the urgent priority queue for traffic class 'B'.
You can create filters that will distinguish different types of IP traffic based upon the settings of the Type of Service (TOS) bits. These TOS filters can be used to assign IPv4 traffic that has particular settings of the TOS bits to a different class and priority than other types of IP traffic. Each filter allows IPv4 traffic whose TOS byte value matches the definition of a configured TOS filter to be assigned a unique traffic class and priority. Configuration of a TOS filter includes a mask value specification to define which bits within the TOS byte are to be matched as well as specification of low and high range values for bits that fall within the mask. The filtering mechanism is based solely on IPv4 TOS values; therefore, it does not rely on identification of IPv4 protocol type or port number information as do most of the other IP filters.
This filter is more expansive in its application than BRS IPv4 precedence filtering, which is concerned only with the high-order 3 bits of the TOS byte. When combined with IP access control support to set TOS bits, BRS TOS bit filter support enables you to perform filtering for traffic that is sent over a secure tunnel, that is fragmented, or that cannot be identified using the BRS UDP and TCP port number filter support. Also, IP access control support allows you to set the TOS bits to a user-defined value instead of having to use the hard-coded precedence bit values for APPN and DLSw that are associated with BRS IPv4 precedence bit filtering. Therefore, it is recommended that you use IP access control and BRS TOS filter support instead of BRS IPv4 precedence bit filtering.
As indicated in Order of Filtering Precedence, TOS filter matches are checked prior to IPv4 precedence bit filters and other IP-specific filters. Checks for the TOS1 to TOS5 filter matches are done sequentially, beginning with the TOS1 filter. Up to 5 TOS filters can be defined.
| Important: | Keep in mind that a packet with a particular TOS value is handled according the first TOS filter definition that the value matches. Be careful to set up your filters so that a particular TOS byte is filtered by the intended filter, not accidentally filtered by a lower-numbered filter. Refer to "Using IP" in Using and Configuring Features for more information. |
BRS normally differentiates IP TCP and UDP traffic according to its port numbers. However, BRS cannot identify the ports after traffic has been encapsulated twice, such as IP traffic transported through an IP secure tunnel or in a secondary UDP or TCP fragment. IP version 4 precedence bit processing has been added to BRS to enable BRS to filter IP secure tunnel packets or TCP and UDP secondary fragment packets.
| Note: | It is recommended that you use BRS IPv4 TOS bit filtering instead of IPv4 precedence bit processing. See IPv4 TOS Bit Filtering for more details. |
When APPN/HPR traffic is being routed over IP, each transmission priority of APPN-HPR (network, high, medium, and low) is mapped to a particular value of the three IP version 4 precedence bits.
When IPv4 precedence filtering is enabled for BRS and the precedence bits in an IP packet match one of the values used for APPN/HPR traffic, then the packet is queued on the priority queue of the BRS t-class to which the corresponding HPR transmission priority is assigned. For example, if an IP packet has a precedence value of '110'b and the BRS HPR-Network filter is assigned to t-class A and priority level normal, then the packet is queued on the normal priority queue of t-class A. If a BRS HPR transmission priority filter is not configured, but the APPN-HPR filter is configured, then the packet is queued on the priority queue and t-class to which the APPN-HPR filter is assigned.
These three kinds of traffic map to the IPv4 precedence value '011'b:
Because several types of traffic map to one value, BRS cannot distinguish between them when it is enabled to filter based on the IPv4 precedence bits. Therefore, when BRS encounters an IP packet with a precedence value of '011'b, it evaluates the BRS filters in the following order to determine whether or not the filter is enabled. When it finds a BRS filter that is configured, the packet is queued on the priority queue and t-class to which the BRS filter is assigned:
If a packet has one of the precedence values that are filtered by BRS, but none of the applicable BRS filter types are configured, the packet is queued on the priority queue and the BRS t-class to which the IP protocol is assigned.
When TN3270 traffic is sent by a client to the 2212 over a wide-area network where BRS is enabled, traffic from the client cannot be prioritized by BRS unless the client sets the precedence bits to '011'b.
You must configure IPv4 precedence bit handling in multiple places:
Perform these three steps to use IPv4 precedence bit filtering:
The SNA/APPN-ISR filter allows you to assign SNA and APPN-ISR traffic that is being bridged to a BRS traffic class. SNA and APPN-ISR traffic is identified as any bridged packets with a destination or source SAP of 0x04, 0x08, or 0x0C and whose LLC (802.2) control field indicates that it is not an unnumbered information (UI) frame.
| Note: | Frame Relay BAN packets are in this category. |
The APPN-HPR filters allow you to assign HPR traffic that is being bridged to a BRS t-class. HPR traffic is identified as any bridge packet with a destination or source SAP of X'04', X'08', X'0C', or X'C8' and whose LLC (802.2) control field indicates it is an unnumbered information (UI) frame.
The Network-HPR, High-HPR, Medium-HPR, and Low-HPR filters allow HPR bridge traffic to further be filtered according to the HPR transmission priority. For example, if you want to assign HPR traffic that uses the network transmission priority to one t-class and priority and all other HPR bridged traffic to a different t-class or priority, you would assign the Network-HPR filter to the appropriate t-class and priority and use the APPN-HPR filter to assign the rest of the HPR traffic to a different t-class or priority.
APPN-HPR traffic that is being routed over IP is filtered using the UDP port number assigned for network, high, medium and low HPR transmission priorities. An additional UDP port number is used for XID exchanges. All of the UDP port numbers used to support APPN-HPR over IP are configurable.
If APPN is not enabled in an intermediate router in the IP network, you can configure UDP port numbers for HPR over IP from the BRS Config> command prompt. If APPN is enabled in the device, BRS will use the values configured at the APPN Config> command prompt.
Other filters may help you to assign traffic. For example, the DLSw filter allows you to assign SNA-DLSw traffic that is being sent over a TCP connection to a BRS t-class.
For SNA/APPN-ISR and APPN-HPR filters, if you want to check for SAPs other than the ones above, create a sliding window filter using MAC filtering and tag that filter. Then assign the tagged MAC filter to a BRS t-class.
It is possible for a packet to match more than one BRS filter type. For example, an IP tunneled bridge packet containing SNA data could match the IP tunneling filter and the SNA/APPN-ISR filter. The order in which the filters are evaluated to determine whether or not a packet matches a BRS filter type is as follows:
| Note: | The protocols for which a filter applies are shown in parentheses. |
| Notes: |
|
t 6
Gateway user configuration
Config>feature brs (1)
Bandwidth Reservation User Configuration
BRS Config>interface 1 (2)
BRS [i 1]Config>enable
Please restart router for this command to take effect.
BRS [i 1] Config>circuit 16 (3)
BRS [i 1][dlci 16] Config>enable
Defaults are in effect for this circuit.
Please restart router for this command to take effect.
BRS [i 1][dlci 16] Config>exit
BRS [i 1]Config>circuit 17
BRS [i 1][dlci 17] Config>enable
Defaults are in effect for this circuit.
Please restart router for this command to take effect.
BRS [i 1][dlci 17] Config>exit
BRS [i 1]Config>circuit 18
BRS [i 1][dlci 18] Config>enable
Defaults are in effect for this circuit.
Please restart router for this command to take effect.
BRS [i 1][dlci 18] Config>
*restart
Are you sure you want to restart the gateway? (Yes or [No]): yes
*t 6
Gateway user configuration
Config>feature brs
Bandwidth Reservation User Configuration
BRS Config>interface 1
BRS[i 1] Config>list
BANDWIDTH RESERVATION listing from SRAM
bandwidth reservation is enabled
interface number 1
maximum queue length 10, minimum queue length 3
total bandwidth allocated 10%
total circuit classes defined (counting one default) 1
class DEFAULT has 10% bandwidth allocated
the following circuits are assigned:
16 using defaults.
17 using defaults.
18 using defaults.
default class is DEFAULT
BRS [i 1] Config>?
ENABLE
DISABLE
SET-CIRCUIT-DEFAULTS
CIRCUIT
ADD-CIRCUIT-CLASS
DEL-CIRCUIT-CLASS
CHANGE-CIRCUIT-CLASS
DEFAULT-CIRCUIT-CLASS
ASSIGN-CIRCUIT
DEASSIGN-CIRCUIT
QUEUE-LENGTH
LIST
SHOW
CLEAR-BLOCK
EXIT
BRS [i 1] Config>set-circuit-defaults (4)
BRS [i 1] [circuit defaults] Config>?
ADD-CLASS
DEL-CLASS
CHANGE-CLASS
DEFAULT-CLASS
TAG
UNTAG
ASSIGN
DEASSIGN
LIST
EXIT
BRS [i 1] [circuit defaults] Config>add (5)
Class name [DEFAULT]?DEF1
Percent bandwidth to reserve [10]? 5
BRS [i 1] [circuit defaults] Config>add
Class name [DEFAULT]?DEF2
Percent bandwidth to reserve [10]?5
BRS [i 1] [circuit defaults] Config>assign ip
Class name [DEFAULT]?DEF1
Priority <URGENT/HIGH/NORMAL/LOW> [NORMAL]?
Frame Relay Discard Eligible <NO/YES> [NO]?
BRS [i 1] [circuit defaults] Config>assign asrt
Class name [DEFAULT]? DEF2
Priority <URGENT/HIGH/NORMAL/LOW> [NORMAL]?
Frame Relay Discard Eligible <NO/YES> [NO]?
BRS[i 1] [circuit defaults] Config>list
BANDWIDTH RESERVATION listing from SRAM
bandwidth reservation is enabled
interface number 1, default circuit
total bandwidth allocated 60%
total classes defined (counting one local and one default) 4
class LOCAL has 10% bandwidth allocated
protocols and filters cannot be assigned to this class.
class DEFAULT has 40% bandwidth allocated
the following protocols and filters are assigned:
protocol ARP with default priority is not discard eligible
protocol DNA with default priority is not discard eligible
protocol VINES with default priority is not discard eligible
protocol IPX with default priority is not discard eligible
protocol OSI with default priority is not discard eligible
protocol VOFR with default priority is not discard eligible
protocol AP2 with default priority is not discard eligible
class DEF1 has 5% bandwidth allocated
the following protocols and filters are assigned:
protocol IP with priority NORMAL is not discard eligible
class DEF2 has 5% bandwidth allocated
the following protocols and filters are assigned:
protocol ASRT with priority NORMAL is not discard eligible
assigned tags:
default class is DEFAULT with priority NORMAL
BRS [i 1] [circuit defaults] Config>exit
BRS [i 1] Config>circuit 16 (6)
BRS [i 1][dlci 161] Config>list
BANDWIDTH RESERVATION listing from SRAM
bandwidth reservation is enabled
interface number 1, circuit number 16 using defaults.
maximum queue length 10, minimum queue length 3
total bandwidth allocated 60%
total classes defined (counting one local and one default) 4
class LOCAL has 10% bandwidth allocated
protocols and filters cannot be assigned to this class.
class DEFAULT has 40% bandwidth allocated
the following protocols and filters are assigned:
protocol ARP with default priority is not discard eligible
protocol DNA with default priority is not discard eligible
protocol VINES with default priority is not discard eligible
protocol IPX with default priority is not discard eligible
protocol OSI with default priority is not discard eligible
protocol VOFR with default priority is not discard eligible
protocol AP2 with default priority is not discard eligible
class DEF1 has 5% bandwidth allocated
the following protocols and filters are assigned:
protocol IP with priority NORMAL is not discard eligible
class DEF2 has 5% bandwidth allocated
the following protocols and filters are assigned:
protocol ASRT with priority NORMAL is not discard eligible
assigned tags:
default class is DEFAULT with priority NORMAL
BRS [i 1] [dlci 16] Config>show
BANDWIDTH RESERVATION currently in RAM
interface number 1, circuit number 16 using defaults.
maximum queue length 10, minimum queue length 3
4 current defined classes:
class LOCAL has 10% bandwidth allocated
class DEFAULT has 40% bandwidth allocated
class DEF1 has 5% bandwidth allocated
class DEF2 has 5% bandwidth allocated
protocol and filter assignments:
Protocol/Filter Class Priority Discard Eligible
--------------- ----- -------- ----------------
IP DEF1 NORMAL NO
ARP DEFAULT NORMAL NO
DNA DEFAULT NORMAL NO
VINES DEFAULT NORMAL NO
IPX DEFAULT NORMAL NO
OSI DEFAULT NORMAL NO
VOFR DEFAULT NORMAL NO
AP2 DEFAULT NORMAL NO
ASRT DEF2 NORMAL NO
BRS [i 1] [dlci 16] Config>exit
BRS [i 1] Config>circuit 17
BRS [i 1] [dlci 17] Config>list
BANDWIDTH RESERVATION listing from SRAM
bandwidth reservation is enabled
interface number 1, circuit number 17 using defaults.
maximum queue length 10, minimum queue length 3
total bandwidth allocated 60%
total classes defined (counting one local and one default) 4
class LOCAL has 10% bandwidth allocated
protocols and filters cannot be assigned to this class.
class DEFAULT has 40% bandwidth allocated
the following protocols and filters are assigned:
protocol ARP with default priority is not discard eligible
protocol DNA with default priority is not discard eligible
protocol VINES with default priority is not discard eligible
protocol IPX with default priority is not discard eligible
protocol OSI with default priority is not discard eligible
protocol VOFR with default priority is not discard eligible
protocol AP2 with default priority is not discard eligible
class DEF1 has 5% bandwidth allocated
the following protocols and filters are assigned:
protocol IP with priority NORMAL is not discard eligible
class DEF2 has 5% bandwidth allocated
the following protocols and filters are assigned:
protocol ASRT with priority NORMAL is not discard eligible
assigned tags:
default class is DEFAULT with priority NORMAL
BRS [i 1] [dlci 17] Config>add-class (7)
This circuit is currently using circuit defaults...
Are you sure you want to override the defaults ?(Yes or [No]): yes
Class name [DEFAULT]? CIRC171
Percent bandwidth to reserve [10]? 5
BRS[i 1] [dlci 17] Config>assign vines
Class name [DEFAULT]? CIRC171
Priority <URGENT/HIGH/NORMAL/LOW> [NORMAL]?
Frame Relay Discard Eligible <NO/YES>[NO]?
BRS [i 1] [dlci 17] Config>list
BANDWIDTH RESERVATION listing from SRAM
bandwidth reservation is enabled
interface number 1, circuit number 17
maximum queue length 10, minimum queue length 3
total bandwidth allocated 65%
total classes defined (counting one local and one default) 5
class LOCAL has 10% bandwidth allocated
protocols and filters cannot be assigned to this class.
class DEFAULT has 40% bandwidth allocated
the following protocols and filters are assigned:
protocol ARP with default priority is not discard eligible
protocol DNA with default priority is not discard eligible
protocol IPX with default priority is not discard eligible
protocol OSI with default priority is not discard eligible
protocol VOFR with default priority is not discard eligible
protocol AP2 with default priority is not discard eligible
class DEF1 has 5% bandwidth allocated
the following protocols and filters assigned:
protocol IP with priority NORMAL is not discard eligible
class DEF2 has 5% bandwidth allocated
the following protocols and filters are assigned:
protocol ASRT with priority NORMAL is not discard eligible
class CIRC171 has 5% bandwidth allocated
the following protocols and filters are assigned:
protocol VINES with priority NORMAL is not discard eligible
assigned tags:
default class is DEFAULT with priority NORMAL
BRS [i 1] [dlci 17] Config>show
BANDWIDTH RESERVATION currently in RAM
interface number 1, circuit number 17
maximum queue length 10, minimum queue length 3
5 current defined classes:
class LOCAL has 10% bandwidth allocated
class DEFAULT has 40% bandwidth allocated
class DEF1 has 5% bandwidth allocated
class DEF2 has 5% bandwidth allocated
class CIRC171 has 5% bandwidth allocated
protocol and filter assignments:
Protocol/Filter Class Priority Discard Eligible
--------------- ----- -------- ----------------
IP DEF1 NORMAL NO
ARP DEFAULT NORMAL NO
DNA DEFAULT NORMAL NO
VINES CIRC171 NORMAL NO
IPX DEFAULT NORMAL NO
OSI DEFAULT NORMAL NO
VOFR DEFAULT NORMAL NO
AP2 DEFAULT NORMAL NO
ASRT DEF2 NORMAL NO
BRS [i 1] [dlci 17] Config>exit
BRS [i 1] Config>set-circuit-defaults
BRS [i 1] [circuit defaults] Config>change DEF1 (8)
Percent bandwidth to reserve [ 5]? 10
BRS [i 1] [circuit defaults] Config>change DEF2
Percent bandwidth to reserve [5]? 10
BRS [i 1] [circuit defaults] Config>list
BANDWIDTH RESERVATION listing from SRAM
bandwidth reservation is enabled
interface number 1, default circuit
total bandwidth allocated 70%
total classes defined (counting one local and one default) 4
class LOCAL has 10% bandwidth allocated
protocols and filters cannot be assigned to this class.
class DEFAULT has 40% bandwidth allocated
the following protocols and filters are assigned:
protocol ARP with default priority is not discard eligible
protocol DNA with default priority is not discard eligible
protocol VINES with default priority is not discard eligible
protocol IPX with default priority is not discard eligible
protocol OSI with default priority is not discard eligible
protocol VOFR with default priority is not discard eligible
protocol AP2 with default priority is not discard eligible
class DEF1 has 10% bandwidth allocated
the following protocols and filters are assigned:
protocol IP with priority NORMAL is not discard eligible
class DEF2 has 10% bandwidth allocated
the following protocols and filters are assigned:
protocol ASRT with priority NORMAL is not discard eligible
assigned tags:
default class is DEFAULT with priority NORMAL
BRS [i 1] [circuit defaults] Config>exit
BRS [i 1] Config>circuit 16
BRS [i 1] [dlci 16] Config>list
BANDWIDTH RESERVATION listing from SRAM
bandwidth reservation is enabled
interface number 1, circuit number 16 using defaults.
maximum queue length 10, minimum queue length 3
total bandwidth allocated 70%
total classes defined (counting one local and one default) 4
class LOCAL has 10% bandwidth allocated
protocols and filters cannot be assigned to this class.
class DEFAULT has 40% bandwidth allocated
the following protocols and filters are assigned:
protocol ARP with default priority is not discard eligible
protocol DNA with default priority is not discard eligible
protocol VINES with default priority is not discard eligible
protocol IPX with default priority is not discard eligible
protocol OSI with default priority is not discard eligible
protocol VOFR with default priority is not discard eligible
protocol AP2 with default priority is not discard eligible
class DEF1 has 10% bandwidth allocated
the following protocols and filters are assigned:
protocol IP with priority NORMAL is not discard eligible
class DEF2 has 10% bandwidth allocated
the following protocols and filters are assigned:
protocol ASRT with priority NORMAL is not discard eligible
assigned tags:
default class is DEFAULT with priority NORMAL
BRS [i 1] [dlci 16] Config>exit
BRS [i 1] Config>circuit 17
BRS [i 1[ [dlci 17] Config>list
BANDWIDTH RESERVATION listing from SRAM
bandwidth reservation is enabled
interface number 1, circuit number 17
maximum queue length 10, minimum queue length 3
total bandwidth allocated 65%
total classes defined (counting one local and one default) 5
class LOCAL has 10% bandwidth allocated
protocols and filters cannot be assigned to this class.
class DEFAULT has 40% bandwidth allocated
the following protocols and filters are assigned:
protocol ARP with default priority is not discard eligible
protocol DNA with default priority is not discard eligible
protocol IPX with default priority is not discard eligible
protocol OSI with default priority is not discard eligible
protocol VOFR with default priority is not discard eligible
protocol AP2 with default priority is not discard eligible
class DEF1 has 5% bandwidth allocated
the following protocols and filters are assigned:
protocol IP with priority NORMAL is not discard eligible
class DEF2 has 5% bandwidth allocated
the following protocols and filters are assigned:
protocol ASRT with priority NORMAL is not discard eligible
class CIRC171 has 5% bandwidth allocated
the following protocols and filters are assigned:
protocol VINES with priority NORMAL is not discard eligible
assigned tags:
default class is DEFAULT with priority NORMAL
BRS [i 1] [dlci 17] Config>use-circuit-defaults (9)
This circuit is currently NOT using circuit defaults...
Are you sure you want to delete current definitions and use defaults ? (Yes or
[No]): yes
Defaults are in effect for this circuit.
Please restart router for this command to take effect.
BRS [i 1] [dlci 17] Config>
*restart
Are you sure you want to restart the gateway? (Yes or [No] ):yes
*t 6
Gateway user configuration
Config>feature brs
Bandwidth Reservation User Configuration
BRS Config>interface 1
BRS [i 1] Config>circuit 17
BRS [i 1] [dlci 17] Config>list
BANDWIDTH RESERVATION listing from SRAM
bandwidth reservation is enabled
interface number 1, circuit number 17 using defaults.
maximum queue length 10, minimum queue length 3
total bandwidth allocated 70%
total classes defined (counting one local and one default) 4
class LOCAL has 10% bandwidth allocated
protocols and filters cannot be assigned to this class.
class DEFAULT has 40% bandwidth allocated
the following protocols and filters are assigned:
protocol ARP with default priority is not discard eligible
protocol DNA with default priority is not discard eligible
protocol VINES with default priority is not discard eligible
protocol IPX with default priority is not discard eligible
protocol OSI with default priority is not discard eligible
protocol VOFR with default priority is not discard eligible
protocol AP2 with default priority is not discard eligible
class DEF1 has 10% bandwidth allocated
the following protocols and filters are assigned:
protocol IP with priority NORMAL is not discard eligible
class DEF2 has 10% bandwidth allocated
the following protocols and filters are assigned:
protocol ASRT with priority NORMAL is not discard eligible
assigned tags:
default class is DEFAULT with priority NORMAL
BRS [i 1] [dlci 17] Config>show
BANDWIDTH RESERVATION currently in RAM
interface number 1, circuit number 17 using defaults.
maximum queue length 10, minimum queue length 3
4 current defined classes:
class LOCAL has 10% bandwidth allocated
class DEFAULT has 40% bandwidth allocated
class DEF1 has 10% bandwidth allocated
class DEF2 has 10% bandwidth allocated
protocol and filter assignments:
Protocol/Filter Class Priority Discard Eligible
--------------- ----- -------- ----------------
IP DEF1 NORMAL NO
ARP DEFAULT NORMAL NO
DNA DEFAULT NORMAL NO
VINES DEFAULT NORMAL NO
IPX DEFAULT NORMAL NO
OSI DEFAULT NORMAL NO
VOFR DEFAULT NORMAL NO
AP2 DEFAULT NORMAL NO
ASRT DEF2 NORMAL NO
BRS [i 1] [dlci 17] Config>exit